The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to mechanisms for handling DNS (domain name system) PTR (pointer) queries and replies across IPv4 and IPv6 Networks.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow IP address to be duplicated across local networks.
Another solution to the lack of available IP addresses is to redesign the address format to allow for more possible IP addresses. The recent introduction of IPv6 provides 128 bits for the IP address, as compared with IPv4 which provides 32 bits for the IP address. However, until all network devices and computers are converted to IPv6, it is still necessary to allow an existing IPv4 device to communicate with an IPv6 device. One popular method that allows IPv4 to IPv6 communication is referred to as protocol translation (NAT-PT). The IP addresses are converted by NAT-PT from one protocol to another protocol (e.g., IPv4 to IPv6 or vice versa) or, more generally, from an external protocol to an internal protocol. In addition to the IP addresses, the NAT-PT also converts any relevant IPv4 or IPv6 information during a protocol translation.
In addition to IP addresses, a packet may also contain address(es), as well as other protocol specific fields, embedded in the payload that require translation. Particular applications may embed address(es) in the payload for various application specific purposes. The current approach for supporting applications which embed IP addresses in the payload in a NAT environment is to add application-specific knowledge (referred to as an application level gateway or ALG) within the NAT device itself. This approach is described in detail in the Internet Engineering Task Force's Request for Comments document RFC 2663, entitled IP “Network Address Translator (NAT) Terminology and Considerations” by P. Srisuresh and M. Holdrege of Lucent Technologies (August 1999), which document is incorporated herein by reference in its entirety.
Domain Name Server applications are examples of applications which use protocol information embedded within DNS type packets. DNS packets will typically include IP addresses and other fields which correspond to either an IPv4 or IPv6 protocol and such DNS packets must be translated before reaching a network having a different protocol. Before a client may communicate with a server, the client performs a DNS (domain name server) query to a DNS device to obtain an IP address of the particular server with which the client wishes to communicate. Name to address mappings are maintained by each DNS server. For instance, IP version 4 name to address mappings are held in “A” records, while IP version 6 name to address mappings are held in “AAAA” records.
Once the IP address of the particular server is obtained by the client from the DNS device, the client can then attempt to communicate with the particular server using the obtained IP address for such server. The client is configured with its own IP address, which it uses to identify itself to the server when communicating with such server.
When a client attempts to communicate with a particular server or server application, some applications are configured to check the validity of the client's reverse mapping before proceeding with interacting with the client. For instance, some telnet applications, after the TCP connection is established and before displaying a “login: prompt:”, check whether the remote client's IP address corresponds to the hostname which the telnet application has used to establish a connection.
When a reverse mapping query is made from a device in a IPv4 network to an IPv6 DNS Server, the query is typically handled by a device that implements NAT-PT which operates to translate the query's IP header from an IPv4 format into an IPv6 format. The query is also handled by a DNS-ALG of the same device which operates to translate the embedded addresses from an IPv4 to an IPv6 format.
RFC2766 states that for translation of IPV4 PTR queries: (i) the string “IN-ADDR.APRA” must be replaced with “IP6.INT” and (ii) the V4 address octets (in reverse order) preceding the string “IN-ADDR.ARPA” must be replaced with the corresponding V6 address octets (if there exists a map) in reverse order. However, the RFC3152 has made the usage of “IP6.INT” obsolete and reflects the IETF consensus that IP6.ARPA domain be used for address to DNS name mapping for the IPv6 address space.
Unfortunately, the migration of DNS servers from an IP6.INT to an IP6.ARPA reverse domain is a gradual process. During this transition, some IPv6 DNS servers that have completely phased out IP6.INT may still be receiving IP6.INT formatted DNS PTR queries, while other IPv6 DNS servers which have not transitioned to IP6.ARPA may be receiving IP6.ARPA formatted DNS PTR queries. A discrepancy between the type of reverse query and configuration of the DNS server will result in a “no answer” reply or sometimes no reply from the DNS server. Thus, in these cases, the client's IP address will fail to be validated by the server and communication fails to be established between the client and server.
In view of the above, there is a need for improved mechanisms for more efficiently and reliably processing DNS PTR queries and replies across IPv4 and IPv6 networks. Additionally, there is a need for reliable handling of queries to IPv6 DNS Servers which have been configured with either or both IP6.ARPA and IP6.INT formats.